Docker Console and Debugger #31

SammySteiner · 2024-06-14T23:04:44Z

Ticket

Resolves Improve debugging during local development #14

Changes

Updated web_console config to allow most local IPs to access the console for local development with docker
Updated docs to give more specific instructions on how to access the debugger

Questions for reviewers

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?
We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?
When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Testing

Add a console statement to a view in the application and confirm that the console shows up in your browser when hitting that page. Test in both native and container modes.
Add a debugger statement to a controller and follow the instructions in the technical-foundation.md doc to attach the debugger. Confirm in both native and container modes.

rocketnova

Thank you for working on this! Left some thoughts below.

docs/app-rails/technical-foundation.md

app-rails/config/environments/development.rb

rocketnova · 2024-06-17T23:32:59Z

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. You said "I was only able to get it running locally". What were you trying to run that was failing with this?

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Co-authored-by: Rocket <[email protected]>

SammySteiner · 2024-06-18T14:53:56Z

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

Sounds good. Thanks for clarifying.

We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. You said "I was only able to get it running locally". What were you trying to run that was failing with this?

The debug gem in the docker ruby 3.3.1-slim image is listed as version 1.9.1, which I was able to confirm on the dockerhub website:

The debug version getting installed in our project is listed as 1.9.2 in our gemfile.lock.
When I try to attach a debugger to the docker container with docker exec -i <Container ID> rdbg -An I get the error in my terminal:

app-rails-1  | 14:42:38 web.1  | DEBUGGER: wait for debugger connection...
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Connected.
app-rails-1  | 14:43:25 web.1  | DEBUGGER: GreetingError: out DEBUGGER: Incompatible version (server:1.9.2 and client:1.9.1)
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Disconnected.

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.

I described how I'm running my docker container in the inline comment here, are you doing it differently?

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Responded to your inline comment.

rocketnova · 2024-06-18T23:54:37Z

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.

I described how I'm running my docker container in the inline comment here, are you doing it differently?

Got it! Thanks. I think what we should do is explicitly install a global version of the debug gem inside the docker image that is used for development, by adding this to line 57 of the Dockerfile:

# Install system-wide gems for development
# This version must match Gemfile.lock. Otherwise, `rdbg` will fail.
RUN gem install debug -v 1.9.2

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Responded to your inline comment.

I think your change is good and that we don't need to expand out to 0.0.0.0.

rocketnova · 2024-06-18T23:56:34Z

docs/app-rails/technical-foundation.md

+    - If you have multiple Rails applications with debuggers running, you'll have to specify the port to attach the debugger to. For more information, see the [Rails debug gem documentation](https://github.com/ruby/debug?tab=readme-ov-file#remote-debugging).
+  - If you're running the app in a container, such as with `make start-container`:
+    - `rdbg` in the terminal on your host machine will not be able to see the port in the container to connect to the debugger. 
+    - Instead, run `rdbg` inside the container: `docker compose exec app-rails rdbg -An`


Running rdbg -An gave me this:

DEBUGGER (client): Connected. PID:10, $0:bin/rails DEBUGGER (client): Type `Ctrl-C` to enter the debug console.

And I needed to hit Ctrl-C to enter the debug console. Whereas rdbg -A allowed me to skip hitting Ctrl-C. Any reason we need -n? I didn't see anything in particular in the docs.

Also, running rdbg (both natively and in the container), I got this:

DEBUGGER (client): Connected. PID:10, $0:bin/rails # No sourcefile available for /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb =>#0 [C] Thread#join at /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb:63 #1 Puma::Single#run at /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb:63 # and 20 frames (use `bt' command for all frames) Stop by SIGURG (rdbg:remote)

This issue is the only reference I found about this. I was able to hit c to continue past it, but it was persistent. Did you run into this?

Thanks! i removed the n from the guidance, however that enables the --nonstop flag which is used to tell rdbg to not stop at the beginning of the script. I saw a bunch of troubleshooting tips that advised adding it, but it's not necessary in all cases.

I was only able to reproduce what you were seeing by connecting the debugger before the application hit the debug statement. But once the debug statement was hit by the user action, then the debugger terminal updated properly.

Oh I see! Thanks.

rocketnova

LGTM. Thank you!

SammySteiner added 2 commits June 14, 2024 18:53

console permissions and update docs

af35910

Merge branch 'main' into sammysteiner/12/improve-debugging

4bc2a02

SammySteiner requested review from rocketnova and ellery-nava June 14, 2024 23:09

rocketnova reviewed Jun 17, 2024

View reviewed changes

SammySteiner and others added 6 commits June 18, 2024 09:24

Update docs/app-rails/technical-foundation.md

6a90973

Co-authored-by: Rocket <[email protected]>

Update docs/app-rails/technical-foundation.md

ccfc86b

Co-authored-by: Rocket <[email protected]>

Update docs/app-rails/technical-foundation.md

b7f3994

Co-authored-by: Rocket <[email protected]>

Update docs/app-rails/technical-foundation.md

8677912

Co-authored-by: Rocket <[email protected]>

Merge branch 'main' into sammysteiner/12/improve-debugging

73c44f7

here are options

cd110c0

SammySteiner requested a review from rocketnova June 18, 2024 14:55

rocketnova reviewed Jun 18, 2024

View reviewed changes

lock debug gem version, small readme update.

63c1bc8

SammySteiner requested a review from rocketnova June 26, 2024 18:45

Merge branch 'main' into sammysteiner/12/improve-debugging

af5256b

rocketnova approved these changes Jun 26, 2024

View reviewed changes

SammySteiner merged commit 7dfcf4f into main Jun 26, 2024
5 checks passed

SammySteiner deleted the sammysteiner/12/improve-debugging branch June 26, 2024 19:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Docker Console and Debugger #31

Docker Console and Debugger #31

SammySteiner commented Jun 14, 2024 •

edited

Loading

rocketnova left a comment

rocketnova commented Jun 17, 2024 •

edited

Loading

SammySteiner commented Jun 18, 2024 •

edited

Loading

rocketnova commented Jun 18, 2024

rocketnova Jun 18, 2024

rocketnova Jun 18, 2024 •

edited

Loading

SammySteiner Jun 26, 2024

rocketnova Jun 26, 2024

rocketnova left a comment

Docker Console and Debugger #31

Docker Console and Debugger #31

Conversation

SammySteiner commented Jun 14, 2024 • edited Loading

Ticket

Changes

Questions for reviewers

Testing

rocketnova left a comment

Choose a reason for hiding this comment

rocketnova commented Jun 17, 2024 • edited Loading

SammySteiner commented Jun 18, 2024 • edited Loading

rocketnova commented Jun 18, 2024

rocketnova Jun 18, 2024

Choose a reason for hiding this comment

rocketnova Jun 18, 2024 • edited Loading

Choose a reason for hiding this comment

SammySteiner Jun 26, 2024

Choose a reason for hiding this comment

rocketnova Jun 26, 2024

Choose a reason for hiding this comment

rocketnova left a comment

Choose a reason for hiding this comment

SammySteiner commented Jun 14, 2024 •

edited

Loading

rocketnova commented Jun 17, 2024 •

edited

Loading

SammySteiner commented Jun 18, 2024 •

edited

Loading

rocketnova Jun 18, 2024 •

edited

Loading